Week Overview
Mon – Fri · 10 hours total
Build a multi-server lab environment and lock it down with professional SSH configuration
Week 1 establishes the infrastructure everything else depends on. By Monday afternoon, students have three Ubuntu 24.04 LTS servers running in Hyper-V with a working NAT gateway. By Friday, those servers are accessible only via SSH key authentication, hardened against brute-force attacks, and monitored by fail2ban. These aren't throw-away exercises — the VMs built this week are the same machines students will configure DHCP, DNS, VPNs, and Docker on for the rest of the course.
Students coming from NETW-0001 will recognise Hyper-V, basic networking, and the SSH concepts. The difference here is scale and intent: three servers with purpose-built network topology, SSH hardened to a professional standard, and fail2ban configured to watch and respond to attack patterns in real time.
Week at a glance
Monday
Lab Environment Build
Course intro, Hyper-V setup, three Ubuntu VMs, vSwitch topology (Lab 1A)
Tuesday
VM Networking & NAT
Static IP config, NAT routing on S1, inter-VM connectivity verification (Lab 1B)
Wednesday
SSH Keys
Key cryptography theory, generate 4096-bit RSA keys, copy to all servers via SCP (Lab 1C)
Thursday
SSH Hardening
sshd_config security options, port change, banners, idle timeout, Windows Terminal sessions
Friday
fail2ban + Assessment
fail2ban install and jail configuration, log monitoring. Mini-Assessment 1.
Learning Outcomes
By end of Week 1, students can…
Build a multi-server Hyper-V labCreate three Ubuntu Server VMs with External, LAN1, and LAN2 vSwitches, correctly configured for the course network topology
Configure NAT routingEnable IP forwarding on S1 and configure iptables masquerade so S2 and S3 reach the internet through S1
Explain SSH key cryptographyDescribe the role of public and private keys, the authentication handshake, and why keys are stronger than passwords
Deploy SSH key authenticationGenerate a 4096-bit RSA key pair on Windows, distribute public keys to all servers via SCP, and disable password authentication
Harden the SSH daemonApply production-grade sshd_config settings: non-default port, login banners, idle timeout, MaxAuthTries, and user access controls
Configure fail2banInstall fail2ban, create a custom jail for SSH, verify it fires on repeated failed attempts, and read its log output
Monday
Course intro + Lab 1A · 2 hrs
Course introduction and lab environment build — three VMs, three vSwitches
0:00–0:30
Lecture
0:30–1:50
Lab 1A
1:50–2:00
Debrief
- Lecture (30 min): Course overview — what NETW-0014 covers, how it builds on NETW-0001, and what the VM environment will look like by Week 8. Walk through the full topology diagram: S1 as a multi-homed NAT gateway (External + LAN1 + LAN2), S2 as the primary internal server (LAN1), S3 as a second internal server (LAN2), additional VMs introduced in Week 6 for VPN testing. Emphasise that every service built in weeks 3–7 runs on these same machines — this is not a sandbox that gets reset.
- Lab 1A (80 min): Host PC configuration (name, static IP). Hyper-V MAC address range per desk. Create three vSwitches: External (physical NIC), LAN1 (internal only), LAN2 (internal only). Create S1 with all three NICs attached. Create S2 with LAN1 only. Create S3 with LAN2 only. Install Ubuntu Server 24.04 LTS on S1 — common config: Secure Boot off, 14 vCPUs, 8192 MB RAM. Ubuntu Server install on S1 begins — students move through partitioning and user account setup.
- Debrief (10 min): Where is everyone? S1 install typically takes 15–20 minutes. If not complete, it will finish overnight or at start of Tuesday. Preview Tuesday: once S1 is running, we configure static IPs on all three servers and test NAT routing before touching SSH.
Instructor note: The three-vSwitch topology is the most important concept to get right on Day 1. Draw it on the board before students open Hyper-V Manager. A student who builds the wrong topology will have compounding problems in every subsequent week. Check each workstation's vSwitch configuration before the end of the session.
Tuesday
Lab 1B · 2 hrs
Complete VM builds, static IP configuration, NAT gateway setup, and connectivity verification
0:00–0:15
Recap
0:15–1:50
Lab 1B
1:50–2:00
Debrief
- Recap (15 min): Verify S1 is fully installed and booting. Anyone still installing S1 — get that finished first. Walk through the expected IP scheme on the board: S1 gets a DHCP address on its External NIC (classroom network) and static addresses on LAN1 and LAN2. S2 and S3 get static addresses on their respective LAN interfaces only. No internet access from S2/S3 until NAT is configured on S1.
- Lab 1B (95 min): Install Ubuntu Server on S2 and S3 (same settings as S1). Configure static IPs on all servers using Netplan (edit
/etc/netplan/ YAML files). Enable IPv4 forwarding on S1 (/etc/sysctl.conf). Configure iptables MASQUERADE rule on S1's External interface. Verify: ping from S2 to S1's LAN1 IP, then ping 8.8.8.8 from S2 — the moment it works through NAT is a satisfying milestone. Repeat verification from S3 via LAN2.
- Debrief (10 min): Review NAT behaviour — why does S2 appear on the classroom network as S1's External IP? Bridge to packet filtering coming in Week 2. Preview Wednesday: now that the network is working, we switch focus to how we access these servers — SSH.
Timing note: Installing Ubuntu Server on two additional VMs while configuring networking is ambitious for one session. If S2 and S3 installs aren't complete by 1:30, have students focus on networking S1 and S2 — S3 can be completed at the start of Wednesday without disrupting the SSH labs.
Wednesday
Lecture + Lab 1C Parts 1–2 · 2 hrs
SSH key cryptography — theory, key generation, and distributing public keys to all servers
0:00–0:10
Recap
0:10–0:40
Lecture
0:40–1:50
Lab 1C Pt 1–2
1:50–2:00
Debrief
- Recap (10 min): Verify all three servers are up and reachable from the host. Quick question: "Right now, how would you connect to S1 from your Windows host?" — likely password SSH. Ask: "What's the problem with password auth on a server?" Take answers — brute force, weak passwords, credential reuse. This motivates today's content.
- Lecture — SSH key cryptography (30 min): How asymmetric encryption works — the public/private key pair analogy (padlock vs. key). The SSH authentication flow: client presents proof it holds the private key; server checks the matching public key in
authorized_keys; no password travels over the wire at any point. Why 4096-bit RSA — brute-forcing a 4096-bit key is computationally infeasible with current and near-future hardware. The two files produced by key generation: private key (never leaves your machine, never shared), public key (safe to copy anywhere — it's useless without the matching private key). Common mistakes: copying the wrong file, wrong permissions on ~/.ssh.
- Lab 1C, Parts 1–2 (70 min): Generate 4096-bit RSA key pair on Windows host using
ssh-keygen. Identify the two files created and their locations. Install openssh-server on all three VMs. Verify SSH connectivity using password auth first. Use SCP to copy the public key to each server's ~/.ssh/authorized_keys. Test key-based login to all three VMs. Create named sessions in Windows Terminal (one per server) for fast access going forward.
Instructor note: The SCP step is where students most often make mistakes — they copy the private key instead of the public, or SCP to the wrong path. Walk through the first server copy as a class demonstration before students work independently.
Thursday
Lab 1D Parts 3–4 · 2 hrs
SSH hardening — disable password auth, change port, banners, idle timeout, and access controls
0:00–0:10
Recap
0:10–1:45
Lab 1D Pt 3–4
1:45–1:55
Bonus
1:55–2:00
Wrap
- Recap (10 min): Verify key-based auth works on all three servers. Ask: "With keys working, what's the very next thing we should do from a security perspective?" — disable password authentication. Today we disable it and then add several layers of additional hardening.
- Lab 1D, Parts 3–4 (95 min):
· Disable password authentication in sshd_config (PasswordAuthentication no) — verify that password login is now rejected.
· Change the SSH port away from 22 — discuss the trade-off: not true security, but reduces noise from automated scanners. Update Windows Terminal sessions to use the new port.
· Configure LoginGraceTime, MaxAuthTries, MaxSessions — explain what each does and set appropriate values.
· Configure idle timeout via /etc/profile — set TMOUT=300, make it readonly and exported. Test it by sitting idle.
· Create the MOTD banner (/etc/motd) — ASCII penguin art from the lab sheet. Create the SSH pre-login banner (/etc/ssh_banner) with a legal disclaimer. Configure Banner directive in sshd_config. Verify both appear at the right moment during connection.
· AllowUsers directive — restrict SSH access to the student account only.
- Bonus (10 min): Explore
/var/log/auth.log — find the SSH login entries. Try a deliberate failed login and watch it appear in the log. This is the direct lead-in to Friday's fail2ban content.
⭐ Thursday Bonus — Reading auth.log
- Run:
sudo tail -f /var/log/auth.log — watch it live while attempting connections from Windows Terminal
- Deliberately enter the wrong password three times — observe the "Failed password" entries appearing in the log
- Ask: "If you were an attacker running a password spray tool, what would this log look like?" — sets up fail2ban perfectly for Friday
Friday
fail2ban + Mini-Assessment 1 · 2 hrs
fail2ban configuration, then Mini-Assessment 1
0:00–0:30
fail2ban lab
0:30–1:15
Assessment
1:15–1:45
Catch-up
1:45–2:00
Review + Preview W2
- fail2ban lab (30 min): Install fail2ban. Explain its mechanism: watches log files for patterns, creates temporary firewall rules to block offending IPs after a threshold is reached. Create
/etc/fail2ban/jail.local with a custom SSH jail — set maxretry = 5, bantime = 600, findtime = 300. Restart fail2ban. Verify the SSH jail is active with fail2ban-client status sshd. Trigger a ban by deliberately failing authentication five times — confirm the ban appears in /var/log/fail2ban.log and that further connections are rejected.
- Mini-Assessment 1 (45 min): Written (15 min) then practical (30 min). Written covers SSH key theory, sshd_config settings, and fail2ban concepts. Practical: students connect to a fresh VM with a deliberately broken SSH config and must diagnose and fix it using only the server's console and man pages.
- Catch-up (30 min): Students who need to complete Lab 1C and 1D sections work independently. Early finishers: explore
fail2ban-client set sshd unbanip [ip] and experiment with different bantime values.
- Review + Week 2 Preview (15 min): Go over the assessment. Preview Week 2: now that the servers are locked down for access, we look at what's happening on the network itself — packet capture with tcpdump and packet generation with Mausezahn.
Mini-Assessment 1 — Topic Coverage
| Topic | Weight | Source |
|---|
| SSH key cryptography — public vs. private key roles, auth handshake | 20% | Wednesday lecture |
| Key generation and SCP distribution — commands and file locations | 15% | Lab 1C Parts 1–2 |
| sshd_config hardening settings — purpose of each directive | 25% | Lab 1D Parts 3–4 |
| Login banners — MOTD vs. SSH banner, when each appears | 10% | Lab 1D Part 4 |
| fail2ban — how it works, jail.local configuration, reading the log | 20% | Friday lab |
| NAT routing — IP forwarding, iptables MASQUERADE, why S2 needs it | 10% | Tuesday lab |
What you need ready before Monday
Ubuntu Server 24.04 LTS ISO on every workstation
Hyper-V enabled on all host machines
Lab 1A, 1B, 1C, and 1D handouts printed
Network IP scheme confirmed per desk
MAC address ranges per desk documented
Mini-Assessment 1 printed (Friday)
Topology diagram drawn and ready for projector